COMPUTER PROGRAM FOR ALLOCATING TRANSACTIONS TO 

OPERATORS 

BACKGROUND OF THE INVENTION 
5 1) Field of the Invention 

The present invention relates to a computer program for 
selecting an appropriate operator, from among a plurality of operators, 
for performing a transaction requested by a customer to thereby make 
even the load on the operators. 

10 

2) Description of the Related Art 

Contact centers or call centers for handling customer supporting 
operation are known in the art. These centers receive transactions 
from the customers via telephone, chat, or e-mail. These transactions 

15 are then processed by the operators associated with theses centers. 
Since there are generally many operators and some of are the 
operators may be already busy processing some other transactions, it is 
required to select an operator to process the transaction and allocate 
the transactions to that operator (hereinafter, "carry out a transaction 

20 allocation processing"). The transaction allocation processing 
according to the conventional art will be briefly explained below. 

The contact center first receives transactions from customers, 
and lists up candidate operators to whom the transactions are allocated. 
For example, when the contact center receives an English transaction, 

25 the contact center lists up operators who can communicate in English 

1 



on the phone. Next, the contact center decides whether the operators 
listed up are available to process the transaction. In other words, the 
contact center decides whether the operators listed up are standby or in 
work based on whether their telephone line is free or in use. 
5 If some operators are standby, then the contact center decides 

for how long these operators were standby based on how long their 
telephone line was free. Then the contact center selects an operator 
who is standby for longest duration and allocates the transaction to that 
operator. The selected operator then processes the transaction. 

10 On the other hand, if none of the operator is standby and the 

transaction is telephone, the contact center sequentially selects e-mail 
processing operators to interrupt from the head to the end or from the 
end to the head of the list. Thus, if the operators are listed up based 
on their IDs, then the contact center sequentially selects operators 

15 whose ID numbers are the smallest or the largest. 

However, according to the above conventional art, there has 
been a problem that the loads of the operators who process the 
transactions are not made even. This problem will be explained with 
reference to Fig. 14. Fig. 14 shows a state of processing transactions 

20 according to the conventional art. The graph in Fig. 14 shows for how 
long each operator was busy. For example, operators with ID numbers 
35 to 70 are in a group of skilled operators who are engaged in 
receiving e-mails in Japanese and receiving telephone calls in 
Japanese. 

25 In this particular group, when the operators are receiving the 
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telephone calls, the operators with lower IDs are busy for a longer time 
than the operators with higher IDs. On the other hand, when the 
operators are receiving the e-mails, the operators with higher IDs are 
busy for a longer time than the operators with lower IDs. This is for 
5 the following reason. In the transaction allocation processing, when 
none of the operators in this group are standby, the telephone 
transactions are sequentially allocated to the operators starting from the 
operators who are at the head of the list, and the e-mail transactions 
currently processed by these operators are interrupted. 

10 In other words, according to the conventional art, when all the 

operators within a predetermined group are currently processing 
transactions, the contact center sequentially selects e-mail processing 
operators starting from the operators who are at the head of the group 
list, and allocates the telephone transactions to these selected 

15 operators. Therefore, when the operators have smaller operator ID 
numbers, the operators' operating times relating to the telephone 
transactions become longer. On the other hand, when the operators 
have larger operator ID numbers, the operators 1 operating times relating 
to the e-mail transactions become longer. As a result, the total 

20 processing times of the transactions of telephone call receptions and 
e-mail receptions are not averaged, and it has not been able to make 
even the load of each operator. 



25 



SUMMARY OF THE INVENTION 

It is an object of the present invention to solve at least the 

3 



problems in the conventional technology. 

According to the apparatus and method of the present invention, 
information such as status of each operator that is information about 
whether the operator is engaged in processing a transaction or he is 
5 standby, how long it will take the operator to complete the transaction 
he is processing at this time, and when the operator started processing 
the transaction is stored. If many operators are standby when a 
transaction is received, one operator is selected, from among the 
standby operators, as an operator to process the transaction. If no 
10 operator is standby, it is estimated when each operator is going to be 
standby and one operator is selected, from among the operators who 
are going to be standby in not more than a predetermined time, as the 
operator to process the transaction. 

The computer program according to the present invention 
15 realizes the method according to the present invention on a computer. 

The other objects, features and advantages of the present 
invention are specifically set forth in or will become apparent from the 
following detailed descriptions of the invention when read in conjunction 
with the accompanying drawings. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows a structure of a system that includes a transaction 
allocation apparatus according to a first embodiment of the present 
invention; 

25 Fig. 2 is a block diagram that shows a structure of the 

4 



transaction allocation apparatus according to the first embodiment; 

Figs. 3A and 3B explain about priority queues and a transaction 
that are managed by a priority queue managing section; 

Figs. 4A and 4B explain about an operator queue and a 
5 transaction that are managed by an operator queue managing section; 

Fig. 5 shows an example of a structure of information stored in 
the operator database; 

Fig. 6 explains about information managed by a processing 
state managing section; 
10 Fig. 7 is a flowchart that shows an outline process of a 

transaction allocation processing; 

Fig. 8 is a flowchart that shows a detailed process of the 
transaction allocation processing; 

Fig. 9 is a flowchart that shows a process of an estimated 
15 standby state list preparation processing; 

Fig. 10 explains about a relationship between an estimated 
standby time and equalization of operator load; 

Fig. 11 shows a state of processing transactions according to 
the present invention; 
20 Fig. 12 shows a structure of a computer system according to a 

second embodiment; 

Fig. 13 is a block diagram that shows a structure of a main body 
of the computer system shown in Fig. 12; and 

Fig. 14 shows a processing state of transactions according to 
25 the conventional art. 



DETAILED DESCRIPTION 

Exemplary embodiments of a transaction allocation program 
according to the present invention will be explained in detail below with 
5 reference to the accompanying drawings. In a first embodiment, a 

transaction allocation apparatus and a transaction allocation method for 
achieving functions similar to those of the transaction allocation 
program according to the present invention will be explained. In a 
second embodiment, a computer system for executing the transaction 

10 allocation program according to the present invention will be explained. 
Last, various modifications of the embodiments will be explained. 

The first embodiment relates to a transaction allocation 
apparatus that achieves functions similar to those of the transaction 
allocation program according to the present invention. An outline of a 

15 system that includes the transaction allocation apparatus according to 
the first embodiment and main characteristics thereof will be explained 
first. Next, a structure of this transaction allocation apparatus will be 
explained. Finally, a process of the transaction allocation processing 
will be explained. 

20 First, the outline of the system that includes the transaction 

allocation apparatus according to the first embodiment will be explained. 
Fig. 1 shows a structure of the system that includes the transaction 
allocation apparatus according to the first embodiment. This system is 
built up in a contact center that receives transactions from customers 

25 via multi-channels such as telephone (i.e., a real-time system), chat 



(i.e., an interactive system), and e-mail (i.e., a non-interactive system), 
and makes a plurality of operators process the received transactions. 

In other words, as shown in Fig. 1, the system receives 
transactions from customer terminals 30 (a group of customer terminals 
5 shown in the drawing) of customers via any one or combinations of 
telephone, chat, and e-mail, and allocates the received transactions to 
operator terminals 40 (a group of operator terminals shown in the 
drawing) of operators. In the operator terminal 40 of each operator, an 
integrated application of the three systems of telephone, chat, and 

10 e-mail operates, and processes the transaction of each system. 

In this system, a transaction allocation apparatus 10 selects an 
operator to process the transactions received from the customers from 
among a plurality of operators, and allocates the transactions to the 
operator terminals 40 of the operator selected. The outline of the 

15 processing of this system will be explained next. 

The transaction allocation apparatus 10 includes a priority 
managing section 11 that stores a plurality of priority queues each 
reflecting high and low priorities. Each priority queue has a queue for 
each of a telephone system class, a chat system class, and an e-mail 

20 system class. A queuing device 50 connected to each channel as an 
entrance to the contact center receives transactions from the customer 
terminals 30 via the three systems of telephone, chat, and e-mail, and 
sets these transactions in predetermined priority queues in the priority 
queue managing section 11 of the transaction allocation apparatus 10. 

25 More specifically, the queuing device 50 determines a class to 



which the transaction received from the customer is to be set in a 
queue, based on the system via which this transaction is received. At 
the same time, the queuing device 50 determines a priority queue to 
which the transaction is to be set, based on a type of a customer ID 
5 (such as a Very Important Person (VIP) customer or a general 
customer), a type of a reception channel (such as a channel 
corresponding to English or Japanese), and information (such as brief 
contents of the transaction) obtained by the Interactive Voice Response 
(IVR) apparatus. The queuing device 50 sets the transaction in a 

10 predetermined class of a predetermined priority queue according to 

these determinations. In other words, when the transaction has a high 
importance level, the queuing device 50 sets this transaction in a 
priority queue of a high priority. When the transaction has a low 
importance level, the queuing device 50 sets this transaction in a 

15 priority queue of a low priority. 

Further, in this queuing, the queuing device 50 sets a type of the 
operation of the transaction (such as Japanese or English), a skill level 
(i.e., a required skilled level) strictly required in the transaction 
processing, a waiting time (i.e., a permissible waiting time) permitted 

20 before the transaction processing is started, based on the system of the 
transaction, the type of the customer ID, the type of the reception 
channel, and the information obtained by the IVR apparatus. The 
queuing device 50 adds the transaction reception time, the required 
skill level, and the permissible waiting time to the transaction, and sets 

25 this transaction in a queue. 



The required skill level is set by taking into account whether a 
communication in English is necessary or whether a considerable 
technical level is required, for example. The permissible waiting time 
is set longer in the order of the telephone system, the chat system, and 
5 the e-mail system. Further, there is a variation such that a shorter 
permissible waiting time is set for a VIP customer. 

The transactions received from the customers based on the 
processing of the queuing device 50 are sequentially queued in 
predetermined classes of predetermined priority queues in the priority 

10 queue managing section 11 of the transaction allocation apparatus 10, 
in the state that each of these transactions is added with the type of the 
operation of the transaction (such as Japanese or English), the 
reception time, the required skilled level, and the permissible waiting 
time (refer to Figs. 3A and 3B). 

15 On the other hand, in the transaction allocation apparatus 10, as 

shown in Fig. 1, an operator queue managing section 12 has an 
operator queue for each operator. Each operator queue has a queue 
for each of the three classes of the telephone system class, the chat 
system class, and the e-mail system class. A controller 15 of the 

20 transaction allocation apparatus 10 sequentially selects operators who 
process the transactions that are queued in the priority queue managing 
section 11, and sequentially allocates the transactions to the operator 
queues of the selected operators, as the transaction allocation 
processing. 

25 In other words, the controller 15 controls to sequentially shift the 



transactions queued in the priority queue managing section 11 of the 
transaction allocation apparatus 10, to predetermined classes of 
predetermined operator queues respectively in the operator queue 
managing section 12 (refer to Figs. 4A and 4B). Each operator 
5 sequentially processes the transactions queued in the own operator 
queue via the operator terminal 40. The transactions queued in the 
operator queue managing section 12 are deleted after the operators 
finish processing these transactions. 

In each operator terminal 40 of each operator, the integrated 

10 application of the three systems including telephone, chat, and e-mail 
operates, and the operator processes the transactions of each system. 
On the other hand, the transaction allocation apparatus 10 interrupts 
transactions to the operators by taking into account the characteristics 
of each system. In other words, when the operator is processing a 

15 transaction in the telephone system, the operator can communicate with 
only one customer at one time. Therefore, the transaction allocation 
apparatus 10 does not interrupt this operator with an additional 
transaction. However, when the operator is processing a transaction in 
the chat or e-mail system, the transaction allocation apparatus 10 

20 interrupts this operator with a telephone transaction, a chat having a 
higher priority, or an e-mail transaction. 

Main characteristics of the system shown in Fig. 1 will be 
explained next. As explained above, according to this system, the 
transaction allocation apparatus 10 allocates the transactions received 

25 from the customers to the operators to make these operators process 



the allocated transactions. In this system, the transaction allocation 
apparatus 10 has main characteristics in its processing. Specifically, 
the transaction allocation apparatus 10 allocates transactions in such a 
way as to average the total processing time for each channel taken by 
5 the same group operator to process transactions, thereby to make even 
the load of the same group operator. The main characteristics will be 
briefly explained based on the outline of the transaction allocation 
processing. 

As shown in Fig. 1, the transaction allocation apparatus 10 has 

10 an operator database (DB) 13 that manages the skill level of each 
operator to process a transaction, and a processing state managing 
section 14 that manages the processing state of transactions processed 
by the operators for each system of telephone, chat, and e-mail (i.e., an 
estimated processing time taken to process the transaction, and a 

15 processing starting time that shows the time when the transaction 
currently under processing has started). The estimated processing 
time shows the estimated time taken to process the transaction. For 
example, an average processing time calculated based on a few past 
records of transaction processing time, or an instantaneous processing 

20 time dynamically estimated with an estimator, is allocated as the 
estimated processing time. 

In the transaction allocation processing, the transaction 
allocation apparatus 10 extracts operators whose skill levels exceed the 
skill level strictly required to process the transaction from the list of the 

25 candidate operators to whom the transaction is allocated, by referring to 



the operators 1 skill levels managed in the operator DB 13. Following 
this extraction, when some operators are standby in their processing 
among the transaction allocation candidate operators, the transaction 
allocation apparatus 10 selects the operator who processes the 
5 transaction from among these standby operators, by referring to the 

processing state managed by the processing state managing section 14. 
Then, the transaction allocation apparatus 10 sets the transaction in the 
operator queue of the selected operator. 

On the other hand, when none of the transaction allocation 

10 candidate operators are standby, the transaction allocation apparatus 
10 relaxes the skill level strictly required to process the transaction, and 
extracts again operators whose skill levels exceed the relaxed skill level 
as transaction allocation candidate operators. Following this 
extraction, when some operators are standby among the transaction 

15 allocation candidate operators extracted again, the transaction 
allocation apparatus 10 selects the operator who processes the 
transaction from among these standby operators, by referring to the 
processing state managed by the processing state managing section 14. 
Then, the transaction allocation apparatus 10 sets the transaction in the 

20 operator queue of this selected operator. 

When none of the transaction allocation candidate operators 
extracted again are standby, the transaction allocation apparatus 10 
subtracts the current time from the sum of the processing starting time 
and the estimated processing time managed by the processing state 

25 managing section 14, and calculates the estimated standby time that 



shows when each transaction allocation candidate operator extracted 
again becomes standby. Following this calculation, the transaction 
allocation apparatus 10 selects the operator who processes the 
transaction from among the operators whose estimated standby times 
5 are under a threshold time, and sets the transaction in the operator 
queue of the selected operator. 

As explained above, when none of the transaction allocation 
candidate operators are standby and the transaction is telephone, 
according to the conventional art, e-mail processing operators are 

10 sequentially selected starting from operators who are at the head or at 
the end of the group list, and each transaction is allocated to each 
selected operator. However, according to the first embodiment, the 
transaction allocation apparatus 10 selects an operator from among 
operators whose estimated standby times are not more than a 

15 predetermined time, and allocates the transaction to this selected 
operator. By allocating the transaction based on the estimated 
standby times, the transaction allocation apparatus 10 can average the 
total processing time for each channel taken by the same group 
operator to process transactions, thereby to make even the load of such 

20 operators. 

A relationship between the estimated standby time and the 
equalization of operator load will be explained. Fig. 10 explains about 
a relationship between an estimated standby time and equalization of 
operator load. Fig. 11 shows a state of processing transactions 

25 according to the present invention. As shown in Fig. 10, an estimated 



processing time that a certain operator has recently taken to process a 
transaction of a certain class is defined as L. Then, the probability that 
the estimated standby time of this operator is not more than the 
constant D becomes D/L when the operator is currently processing a 
5 certain transaction. 

The number of times when this operator has recently processed 
transactions is obtained by multiplying the number of opportunities 
when transactions are allocated to this operator (which is the same 
number for all the operators in the same group) by the probability D/L. 

10 The total processing time when this operator has recently processed 
transactions is obtained by multiplying the estimated processing time L 
when the operator has recently taken to process the transaction by the 
number of times when this operator has recently processed transactions. 
In other words, "the total processing time recently taken to process 

15 transactions" = "the number of opportunities when transactions are 
allocated to the operator (which is the same number for all the 
operators in the same group)" x "the predetermined constant D". 

Therefore, when none of the allocation candidate operators (i.e., 
the operators in the same group) are standby, by allocating transactions 

20 to the operators whose estimated standby times are not more than the 
predetermined constant D, the total processing time recently taken by 
each operator to process transactions becomes substantially the same 
for all the operators in the same group, regardless of a variation in the 
estimated processing time taken by each operator to process a 

25 transaction, as shown in the above expression. 



In other words, as shown in Fig. 11, according to the above 
transaction allocation processing, it becomes possible to average the 
total processing time for such channel taken by the same group 
operator to process transactions of each system, thereby to make 
5 even the load of each operator. Therefore, unlike the conventional art, 
it becomes possible to avoid such a situation that the operating times of 
the same group operators of smaller operator ID numbers who process 
the telephone transactions become longer (refer to the group of 
operators skilled in Japanese shown in Fig. 14, for example). 

10 The structure of each section of the transaction allocation 

apparatus 10 according to the first embodiment will be explained below. 
Fig. 2 is a block diagram that shows the structure of the transaction 
allocation apparatus 10 according to the first embodiment. As shown 
in Fig. 2, the transaction allocation apparatus 10 includes the priority 

15 queue managing section 11, the operator queue managing section 12, 
the operator DB 13, the processing state managing section 14, and the 
controller 15. 

The priority managing section 11 manages transactions queued 
by the queuing device 50, and has a plurality of priority queues each 

20 reflecting high and low priorities. Each priority queue has a queue for 
each of the three classes of the telephone system class, the chat 
system class, and the e-mail system class. Specifically, the priority 
managing section 11 manages the transactions received from 
customers in the state that the transactions are queued in each class of 

25 each priority queue as shown in Fig. 3A. 



As explained above, the queuing device 50 sets transactions of 
a high importance level in a priority queue of a high priority level, based 
on the type of a customer ID, the type of a reception channel, and the 
information obtained by the Interactive Voice Response (IVR) apparatus 
5 When the transactions have a low importance level, the queuing device 
50 sets these transactions in a priority queue of a low priority. Further, 
as shown in Fig. 3B, the queuing device 50 sets each transaction in the 
queue in the state that the type of the operation of the transaction (such 
as Japanese or English), the skill level (i.e., the required skilled level) 

10 strictly required in the transaction processing, the transaction reception 
time, and the permissible waiting time permitted before the transaction 
processing is started, are added to the transaction. 

The operator queue managing section 12 manages the 
transactions allocated to the operators based on the control of the 

15 controller 15, and has an operator queue for each operator. Each 
operator queue has a queue for each of the three classes of the 
telephone system class, the chat system class, and the e-mail system 
class. Specifically, as shown in Fig. 4A, the operator queue managing 
section 12 manages the transactions in the state that each transaction 

20 shifted from the priority queue managing section 11 is set in a queue to 
each class of each operator. In queuing the transactions shifted from 
the priority queue managing section 11, the operator queue managing 
section 12 queues the transactions in the state that a queuing time that 
shows the time of queuing is added to each transaction, as shown in 

25 Fig. 4B. 



The operator DB 13 is the database based on which the skill 
level of each operator to process each transaction is managed. 
Specifically, as shown in Fig. 5, the skill level of each operator to 
process the transaction of each of the telephone system, the chat 
5 system, and the e-mail system is managed corresponding to the ID 
number of each operator by type of the operation such as Japanese or 
English. 

The processing state managing section 14 manages the 
processing state in which each operator processes each transaction, for 

10 each operator. Specifically, as shown in Fig. 6, the standby state 

managing section 14 manages the processing state of each operator by 
mutually relating information that shows whether the operator is 
standby (i.e., whether the operator is currently processing a 
transaction), a standby state starting time that shows when a standby 

15 state started when the operator is currently standby, a processing 

starting time that shows when the processing started when the operator 
is currently processing a transaction, and an estimated processing time 
taken to process the transaction, for each of the telephone system, the 
chat system, and the e-mail system, corresponding to each operator ID 

20 number. 

The controller 15 has internal memories that store a control 
program such as an operating system (OS), a program that prescribes 
various kinds of processing procedures, and required data. The 
controller 15 executes the transaction allocation processing based on 
25 these programs and data. As a concept of functions, as shown in Fig. 



2, the controller 15 has a priority queue selector 16, a strict skill 
matching section 17, a strict skill list preparing section 18, a standby 
state deciding section 19, a standby state list preparing section 20, an 
operator selector 21 , a transaction processor 22, a permissible waiting 
5 time deciding section 23, a relaxed skill matching section 24, a relaxed 
skill list preparing section 25, an estimated standby time calculating 
section 26, an estimated standby state list preparing section 27, and a 
transaction reallocation section 28. 

The priority queue selector 16 selects a predetermined priority 
10 queue to which transactions are allocated, according to a probability set 
in advance based on the priority queues of the priority queue managing 
section 11. The preset probability is set in advance such that a priority 
queue of a higher priority is selected more often than a priority queue of 
a lower priority. 

15 The priority queue selector 16 sequentially selects the telephone 

system class, the chat system class, and the e-mail system class based 
on the selected priority queues, and starts the allocation of the 
transactions queued in each class. In other words, the priority queue 
selector 16 starts the allocation of the transactions included in the 

20 telephone system class. After finishing the allocation of these 

transactions, the priority queue selector 16 starts the allocation of the 
transactions included in the chat system class. After finishing the 
allocation of these transactions, the priority queue selector 16 starts the 
allocation of the transactions included in the e-mail system class. 

25 After the allocation of all the transactions of all the classes is finished, 



the priority queue selector 16 selects priority queues. 

The strict skill matching section 17 matches the required skill 
level strictly required to process the transaction (refer to Fig. 3B) with 
the skill level of each operator managed in the operator DB 13, for each 
5 transaction of each class of the priority queue selected by the priority 
queue selector 16. 

The strict skill list preparing section 18 extracts operators whose 
skill levels exceed the required skill level based on the result of the 
matching by the strict skill matching section 17, and prepares a strict 
10 skill list that lists up the extracted operators. 

The standby state deciding section 19 decides whether each 
operator is standby by referring to the processing state managing 
section 14, for each operator listed up in the strict skill list. Specifically, 
the standby state deciding section 19 decides whether each operator is 
15 standby in the processing of transactions of the system corresponding 
to the transaction system such as the telephone system, the chat 
system, or the e-mail system, to which the transaction is to be 
allocated. 

When the relaxed skill list preparing section 25 has prepared a 
20 relaxed skill list as described later, the standby state deciding section 
19 decides whether each operator is standby by referring to the 
processing state managing section 14, for each operator listed up in the 
relaxed skill list. 

In deciding the standby state by the standby state deciding 
25 section 19, it is possible to change the concept of "standby" according 



to the type of the skill list. In other words, in deciding the standby 
state of the operators in the strict skill list, the standby state deciding 
section 19 may decide that the operators who are standby in their 
processing of all the types of telephone, chat, and e-mail systems are 
5 "standby". On the other hand, in deciding the standby states of the 
operators in the relaxed skill list, the standby state deciding section 19 
may decide that the operators who are standby in their processing of 
types of systems to which the transactions are to be allocated are 
"standby". 

10 Further, in deciding the standby state by the standby state 

deciding section 19, it is also possible to change the concept of 
"standby" according to the type of the transactions to be allocated. In 
other words, when the type of the transactions to be allocated is the 
telephone, the standby state deciding section 19 may decide that not 

15 only the operators who are standby in their processing of all the types 
of telephone, chat, and e-mail systems but also the operators who are 
currently processing only the e-mail transactions are "standby". In this 
case, the standby state deciding section 19 decides that the operators 
who are currently processing the transactions of the telephone or the 

20 chat systems are "not standby". 

The standby state list preparing section 20 extracts operators 
who are standby in their processing based on the result of the decision 
made by the standby state deciding section 19. The standby state list 
preparing section 20 further prepares a standby state list by listing up 

25 the operators whose standby times are the longest by referring to the 



processing state managing section 14, for the extracted operators. 
Specifically, the standby state list preparing section 20 lists up in the 
standby state list the operators whose "standby state starting time" 
managed by the processing state managing section 14 is the longest. 
5 The operator selector 21 selects an operator who processes a 

transaction from among the operators listed up in the standby state list. 
Specifically, when one operator is listed up in this standby state list, the 
operator selector 21 selects this operator as the operator who process 
the transaction. When there are a plurality of operators listed up in 

10 this standby state list, the operator selector 21 selects an operator 
whose skill level exceeds by minimum the required skill level (or the 
skill level relaxed from this level) to process the transaction as the 
operator who processes the transaction, by referring to the result of the 
matching carried out by the strict skill matching section 17 (or the 

15 relaxed skill matching section 24 as described later). 

When the estimated standby state list preparing section 27 has 
prepared an estimated standby state list, the operator selector 21 
selects an operator who processes a transaction from among the 
operators listed up in this estimated standby state list. Specifically, in 

20 a similar manner to that based on the standby state list, when one 
operator is listed up in this estimated standby state list, the operator 
selector 21 selects this operator as the operator who processes the 
transaction. When there are a plurality of operators listed up in this 
estimated standby state list, the operator selector 21 selects an 

25 operator whose skill level exceeds by minimum the skill level relaxed 



from the skill level required to process the transaction as the operator 
who processes the transaction, by referring to the result of the matching 
carried out by the relaxed skill matching section 24 as described later. 
The reason why the operator selector 21 selects the operator 
5 whose skill level exceeds by minimum the required skill level (or the 
skill level relaxed from this level) to process the transaction as the 
operator who processes the transaction is to take into account the cost 
of the contact center. In other words, the cost becomes larger when 
the operator selector 21 selects the operator whose skill level exceeds 
10 by a large amount the required skill level (or the skill level relaxed from 
this level) to process the transaction as the operator who processes the 
transaction. 

The transaction processor 22 sets the transaction to be 
allocated in the operator queue (in the operator queue managing 

15 section 12) of the operators selected by the operator selector 21 , and 
deletes the transaction from the priority queue managing section 11. 

When the standby state deciding section 19 has decided that 
none of the operators are standby by referring to the strict skill list, the 
permissible waiting time deciding section 23 decides whether the 

20 current time exceeds the permissible waiting time, based on the 

reception time of each transaction to be allocated and the permissible 
waiting time (refer to Fig and 3B). When the current time does not 
exceed the permissible waiting time, this transaction allocation 
processing is postponed (that is, this transaction is to be allocated later 

25 again), and the allocation of the next transaction in the priority queue is 



started. 

When the permissible waiting time deciding section 23 has 
decided that the current time exceeds the permissible waiting time of 
the transaction to be allocated, the relaxed skill matching section 24 
5 matches the skill level relaxed from the skill level strictly required to 
process the transaction (refer to Fig. 3B) with the skill level of each 
operator managed in the operator DB 13. 

The relaxed skill list preparing section 25 extracts operators 
whose skill levels exceed the relaxed skill level based on the result of 
10 the matching carried out by the relaxed skill matching section 24, and 
prepares the relaxed skill list that lists up the extracted operators. 

The reason why the relaxed skill list preparing section 25 
prepares the relaxed skill list by relaxing the required skill level when 
the current time exceeds the permissible waiting time of the transaction 
15 to be allocated is that the customer satisfaction level is considered 
higher when the transaction is allocated to the operator who has the 
relaxed skill level than when a long waiting time that exceeds the 
permissible waiting time is forced to the customer. Further, this is also 
because it becomes possible to make even the load of each operator 
20 group based on the skill level (refer to Fig. 11). 

On the other hand, the reason why the transaction allocation 
processing is postponed when the current time does not exceed the 
permissible waiting time is that it is not considered necessary to 
allocate the transaction to the operator who has the relaxed skill level 
25 when the current time does not exceed the permissible waiting time. 



When the relaxed skill list preparing section 25 has prepared the 
relaxed skill list, the standby state deciding section 19 decides whether 
each operator is standby by referring to the processing state managing 
section 14 for each operator listed up in the relaxed skill list. 
5 When the standby state deciding section 19 has decided that 

none of the operators are standby by referring to the relaxed skill list, 
the estimated standby time calculating section 26 subtracts the current 
time from the sum of the processing starting time and the estimated 
processing time managed by the processing state managing section 14, 
10 and calculates the estimated standby time that shows the estimated 
time when each operator listed up in the relaxed skill list becomes 
standby. 

The estimated standby state list preparing section 27 extracts 
operators whose estimated standby times are smaller than the 

15 predetermined constant D (refer to Fig. 10) based on the estimated 

standby time of each operator calculated by the estimated standby time 
calculating section 26, and prepares the estimated standby state list 
that lists up the extracted operators. When the estimated standby 
state list preparing section 27 has prepared the estimated standby state 

20 list, the operator selector 21 selects operators who process the 
transactions from among the operators who are listed up in the 
estimated standby state list. 

The transaction reallocation section 28 monitors the 
transactions queued in the operator queue managing section 12. 

25 When the operator does not start the processing of a transaction within 



a predetermined time, the transaction reallocation section 28 cancels 
the allocation of this transaction, and returns the transaction to the 
priority queue of the priority queue managing section 11 (for example, 
the original priority queue or a priority queue of which priority is higher 
5 than that of the original priority queue). The returned transaction is to 
be allocated again. The reason why the transaction reallocation 
section 28 returns the once-allocated transaction is to avoid the 
occurrence of a customer's long waiting time, by flexibly coping with the 
situation when the operator's estimated standby time is wrong. 

10 Next, the process in which the transaction allocation apparatus 

10 allocates transactions will be explained. Figs. 7 to 9 are flowcharts 
that show the process of the transaction allocation processing. More 
specifically, Fig. 7 shows an outline process of the transaction 
allocation processing, Fig. 8 shows a detailed process of the 

15 transaction allocation processing, and Fig. 9 shows a process of the 
estiamted standby state list preparation processing. The process of 
the transaction allocation processing will be explained below with 
reference to Figs. 7 to 9. 

The outline process of the transaction allocation processing will 

20 be explained with reference to Fig. 7. As shown in Fig. 7, in the 
transaction allocation apparatus 10, the priority queue selector 16 
selects a predetermined priority queue to which transactions are 
allocated, according to a probability set in advance (step S701). Next, 
the priority queue selector 16 selects the telephone system class from 

25 the selected priority queue (step S702), and executes the allocation of 



each transaction included in this telephone system class (step S703). 

When the allocation of each transaction included in the 
telephone system class has been finished, the priority queue selector 
16 selects the chat system class from the selected priority queue (step 
5 S704), and executes the allocation of each transaction included in this 
chat system class (step S705). 

When the allocation of each transaction included in the chat 
system class has been finished, the priority queue selector 16 selects 
the e-mail system class from the selected priority queue (step S706), 

10 and executes the allocation of each transaction included in this e-mail 
system class (step S707). When the allocation of each transaction 
included in the e-mail system class has been finished, the priority 
queue selector 16 selects a priority queue again (step S701). 

Through the above series of processing, each transaction 

15 queued in each priority queue of the priority queue managing section 11 
is sequentially queued in a predetermined operator queue of the 
operator queue managing section 12. 
[Detailed process of the transaction allocation processing] 

A detailed process of the transaction allocation processing, that 

20 is, the process of the processing at steps S703, S705, and S707 shown 
in Fig. 7, will be explained with reference to Fig. 8. As shown in Fig. 8, 
in the transaction allocation apparatus 10, the priority queue selector 16 
selects a transaction from the selected class (step S801). When a 
transaction of the telephone system class is to be allocated (as shown 

25 at step S703 in Fig. 7), the priority queue selector 16 selects a 



transaction at the head of the telephone system class in the priority 
queue. 

The strict skill matching section 17 matches the required skill 
level required to process the transaction with the skill level of each 
5 operator managed in the operator DB 13, for the transaction selected at 
step S801 (step S802). Next, the strict skill list preparing section 18 
extracts operators whose skill levels exceed the required skill level 
based on the result of the matching by the strict skill matching section 
17, and prepares the strict skill list that lists up the extracted operators 

10 (step S803). 

Next, the standby state deciding section 19 decides whether 
each operator is standby by referring to the processing state managing 
section 14, for each operator listed up in the strict skill list (step S804). 
The standby state deciding section 19 decides that the operators who 

15 are standby in their processing of all the types of telephone, chat, and 
e-mail systems are "standby". When the type of the transaction to be 
allocated is telephone, the standby state deciding section 19 decides 
that the operators who are currently processing only the e-mail 
transactions are also "standby". 

20 When the standby state deciding section 19 has decided that 

some operators are standby (Yes at step S804), the standby state list 
preparing section 20 extracts operators who are standby in their 
processing based on the result of the decision made by the standby 
state deciding section 19. The standby state list preparing section 20 

25 further prepares the standby state list by listing up the operators whose 



standby times are the longest by referring to the processing state 
managing section 14, for the extracted operators (step S805). 

The operator selector 21 decides whether there are a plurality of 
operators listed up in this standby state list (step S806). When only 
5 one operator is listed up in this standby state list (No at step S806), the 
operator selector 21 selects this operator as the operator who 
processes the transaction (step S808). On the other hand, when there 
are a plurality of operators listed up in this standby state list (Yes step 

5806) , the operator selector 21 selects an operator whose skill level 
10 exceeds the skill level required to process the transaction by minimum 

as the operator who processes the transaction, by referring to the result 
of the matching carried out by the strict skill matching section 17 (step 

5807) . 

The transaction processor 22 sets the transaction to be 
15 allocated in the operator queue (in the operator queue managing 

section 12) of the operators selected by the operator selector 21, and 
deletes the transaction from the priority queue managing section 11 
(step S809). 

The priority queue selector 16 decides whether there are 
20 transactions remaining in the selected class (step S810). When there 
are transactions remaining in the selected class (Yes step S810), the 
priority queue selector 16 selects the next transaction to be allocated 
(step S801). On the other hand, when there are no more transactions 
remaining in the selected class (No step S810), the priority queue 
25 selector 16 finishes the allocation processing of this class. 



When the standby state deciding section 19 has decided that 
none of the operators are standby by referring to the strict skill list at 
step S804 (No at step S804), the permissible waiting time deciding 
section 23 decides whether the current time exceeds the permissible 
5 waiting time, based on the reception time of each transaction to be 
allocated and the permissible waiting time (step S811). When the 
permissible waiting time deciding section 23 has decided that the 
current time does not exceed the permissible waiting time (No at step 
S811), this transaction allocation processing is postponed. Then, the 

10 priority queue selector 16 decides whether there are transactions 
remaining in the selected class (step S810). 

On the other hand, when the permissible waiting time deciding 
section 23 has decided that the current time exceeds the permissible 
waiting time (Yes at step S811), the relaxed skill matching section 24 

15 matches the skill level relaxed from the skill level strictly required to 
process the transaction with the skill level of each operator managed in 
the operator DB 13 (step S812). The relaxed skill list preparing 
section 25 extracts operators whose skill levels exceed the relaxed skill 
level based on the result of the matching carried out by the relaxed skill 

20 matching section 24, and prepares the relaxed skill list that lists up the 
extracted operators (step S813). 

Next, the standby state deciding section 19 decides whether 
each operator is standby by referring to the processing state managing 
section 14, for each operator listed up in the relaxed skill list (step 

25 S814). In other words, the standby state deciding section 19 decides 



that the operators who are standby in their processing of the system 
corresponding to the type of the transaction to be allocated are 
"standby". 

When the standby state deciding section 19 has decided that 
5 some operators are standby (Yes at step S814), the standby state list 
preparing section 20 extracts operators who are standby in their 
processing based on the result of the decision made by the standby 
state deciding section 19. The standby state list preparing section 20 
further prepares the standby state list by listing up the operators whose 
10 standby times are the longest by referring to the processing state 
managing section 14, for the extracted operators (step S805). 

Next, the processing at steps S806 to S810 is carried out. At 
step S807, unlike the contents of the processing at the above same 
step, the operator selector 21 selects an operator whose skill level 
15 exceeds by minimum the skill level relaxed from the skill level required 
to process the transaction as the operator who processes the 
transaction, by referring to the result of the matching carried out by the 
relaxed skill matching section 24. 

At step S814, when the standby state deciding section 19 has 
20 decided that none of the operators are standby (No at step S814), the 
estimated standby time calculating section 26 and the estimated 
standby state list preparing section 27 prepare the estimated standby 
state list (step S815). 

When the estimated standby state list has been prepared, the 
25 processing at steps S806 to S810 is carried out. At step S807, the 



operator selector 21 selects an operator whose skill level exceeds the 
skill level required to process the transaction by minimum as the 
operator who processes the transaction, by referring to the result of the 
matching carried out by the relaxed skill matching section 24, in a 
5 similar manner to that of the above same step. 

Through the above series of processing, each transaction of a 
predetermined class in a predetermined priority queue is sequentially 
allocated and queued in the operator queue of the operator who 
processes the transactions. 

10 The process of the estimated standby state list preparation, that 

is, the process of the processing at step S815 shown in Fig. 8, will be 
explained with reference to Fig. 9. As shown in Fig. 9, in the 
transaction processing apparatus 10, the estimated standby time 
calculating section 26 selects a predetermined operator from the 

15 relaxed skill list (for example, the operator at the head in the list) (step 
S901). The estimated standby time calculating section 26 subtracts 
the current time from the sum of the processing starting time and the 
estimated processing time managed by the processing state managing 
section 14, and calculates the estimated standby time (step S902). 

20 The estimated standby state list preparing section 27 decides 

whether the estimated standby time is smaller than the predetermined 
constant D based on the estimated standby time of each operator 
calculated by the estimated standby time calculating section 26 (step 
S903). When the estimated standby time is smaller than the 

25 predetermined constant D (Yes at step S903), the estimated standby 



state list preparing section 27 lists this operator in the estimated 
standby state list (step S904). When the estimated standby time is not 
smaller than the predetermined constant D (No at step S903), the 
estimated standby state list preparing section 27 does not list this 
5 operator in the estimated standby state list. 

The estimated standby state list preparing section 27 decides 
whether the estimated standby times of all the operators listed up in the 
relaxed skill list are calculated (step S905). When the estimated 
standby times of all the operators listed up in the relaxed skill list are 

10 calculated (Yes at step S905), the estimated standby state list preparing 
section 27 finishes the estimated standby state list preparation 
processing. On the other hand, when the estimated standby times of 
all the operators are not calculated (No at step S905), the estimated 
standby time calculating section 26 selects the next operator from the 

15 relaxed skill list (step S901), and calculates the estimated standby 
time of this operator (step S902). 

Through the above series of processing, the estimated standby 
state list that sequentially lists up the operators whose estimated 
standby times are smaller than the predetermined constant D is 

20 prepared, from the operators listed up in the relaxed skill list. 

It is possible to realize the transaction allocation apparatus and 
the transaction allocation method explained in the first embodiment by 
executing a program prepared in advance with a computer system such 
as a personal computer and a workstation. In a second embodiment, 

25 the computer system for executing a transaction allocation program 



having similar function to those of the transaction allocation apparatus 
and the transaction allocation method explained in the first embodiment 
will be explained. 

Fig. 12 shows a structure of a computer system according to the 
5 second embodiment of the present invention. Fig. 13 is a block 

diagram that shows a structure of a main body of the computer system. 
As shown in Fig. 12, a computer system 100 according to the second 
embodiment has a main body 101, a display 102 that displays 
information such as an image on a display screen 102a based on an 
10 instruction from the main body 101, a keyboard 103 from which various 
kinds of information are input to the computer system 100, and a mouse 
104 used to assign an optional position on the display screen 102a of 
the display 102. 

As shown in Fig. 13, the main body 101 of this computer system 
15 100 has a Central Processing Unit (CPU) 121, a Random Access 

Memory (RAM) 122, a Read-Only Memory (ROM) 123, a hard disk drive 
(HDD) 124, a CD-ROM drive 125 that accommodates and drives a 
CD-ROM 109, an FD drive 126 that accommodates and drives a flexible 
disk (FD) 108, an I/O interface 127 that connects between the display 
20 102, the keyboard 103, and the mouse 104, and a LAN interface 128 

that connects the system to a local area network or a wide area network 
(LAN/WAN) 106. 

The computer system 100 is connected with a modem 105 to 
connect the system to a public network 107 such as the Internet. 
25 Further, the computer system 100 is connected to other computer 



system (PC) 111, a server 112, and a printer 113, via the LAN interface 
128 and the LAN/WAN 106. 

The computer system 100 reads the transaction allocation 
program recorded on a predetermined recording medium and executes 
5 this program, thereby to realize the transaction allocation apparatus 
and the transaction allocation method. The predetermined recording 
medium includes all kinds of recording mediums for recording the 
transaction allocation program that can be read by the computer system 
100, including a "portable physical medium" such as the flexible disk 

10 (FD) 108, the CD-ROM 109, an MO disk, a DVD disk, an optical 

magnetic disk, and an IC card, a "fixed physical medium" such as the 
hard disk drive (HDD) 124, the RAM 122, and the ROM 123 provided 
inside or outside the computer system 100, and a "communication 
medium" that holds the program for a short period of time to transmit 

15 the program such as the public network 107 connected to the system 
via the modem 105, and the LAN/WAN 106 that connects the system 
with the other computer system 111 and the server 112. 

In other words, the transaction allocation program is recorded 
on the "portable physical medium", the "fixed physical medium", and the 

20 "communication medium" so that this program can be read by the 

computer. The computer system 100 reads the transaction allocation 
program from these recording mediums, and executes this program, 
thereby to realize the transaction allocation apparatus and the 
transaction allocation method. It is also possible to apply the present 

25 invention when the other computer system 111 or the server 112 



executes the transaction allocation program or when the other computer 
system 111 and the server 112 operate with each other to execute the 
transaction allocation program. 

While the present invention has been explained based on the 
5 above embodiment, it is also possible to apply the present invention in 
various different embodiments within the range of the technical idea 
described in the scope of claim for a patent. 

In the above embodiment, it is explained that when none of the 
allocation candidate operators are standby, an operator whose 

10 estimated standby time is not more than a predetermined time is 

selected as the operator who processes a transaction. However, the 
present invention does not limit the allocation method to this method, 
and it is also possible that an operator whose estimated standby time 
is the shortest is selected as the operator who processes a transaction. 

15 In the above embodiment, it is explained that an operator who 

processes a transaction is selected based on an estimated standby 
time through the process of matching the skill with the relaxed skill. 
However, the present invention does not limit the allocation method to 
this method, and it is also possible that an operator who processes a 

20 transaction is selected based on an estimated standby time through 
only the process of matching the skill with the strict skill without through 
the process of matching the skill with the relaxed skill. 

In the above embodiment, the whole or a part of the processing 
explained to be carried out automatically can be carried out manually. 

25 Further, the whole or a part of the processing explained to be carried 



out manually can be carried out automatically according to a known 
method. It is possible to change optionally, except where specified 
otherwise, the information that includes the processing processes, the 
control processes, the detailed names, and the various kinds of data 
5 and parameters shown in the document and in the drawings. 

The constituent elements of the apparatuses shown in the 
drawings show only the concept of their functions, and it is not always 
necessary to have physical structures as shown in the drawings. In 
other words, detailed formats of disintegration and integration of the 

10 apparatuses are not limited to those shown in the drawings. It is also 
possible to structure the whole or a part of the apparatuses by 
functionally or physically disintegrating or integrating the apparatuses in 
optional units according to various kinds of loads and using states. 
Further, it is also possible to realize the whole or an optional part of the 

15 processing functions executed by the apparatuses, by the CPU or 

based on the program that is analyzed and executed by the CPU, or as 
hardware according to the wired logic control. 

As explained above, according to the present invention, when 
none of the transaction allocation candidate operators are standby in 

20 their processing, the operator who processes a transaction is selected 
based on the estimated standby time, and the transaction is allocated 
to the selected operator. Therefore, it becomes possible to average 
the total processing time for each channel taken by the same group 
operator to process transactions, thereby to make even the load of the 

25 same group operator. 



Furthermore, the estimated standby time is calculated flexibly 
according to the variation in the estimated processing time. Therefore, 
it becomes possible to average the total processing time for each 
channel taken by the same group operator to process transactions, 
5 thereby to make even the load of the same group operator, while taking 
into account the variation in the estimated processing time taken by 
each operator. 

Moreover, a simple selection method is employed such that an 
operator whose estimated standby time is the shortest is selected as 

10 the operator who processes a transaction. Therefore, it becomes 

possible to average the total processing time for each channel taken by 
the same group operator to process transactions, thereby to make even 
the load of the same group operator. 

Furthermore, a transaction is allocated to an operator whose 

15 estimated standby time is not more than a predetermined time. 

Therefore, the total processing time taken by each operator to process 
transactions becomes substantially the same, regardless of the 
variation in the estimated processing time taken by each operator. In 
other words, it becomes possible to average the total processing time 

20 taken by each operator to process transactions, thereby to make even 
the load of each operator. 

Moreover, a once-allocated transaction is allocated again. 
Therefore, it is possible to avoid the occurrence of a customer's long 
waiting time, by flexibly coping with the situation when the operator's 

25 estimated standby time is wrong. 



Furthermore, when each operator is a contact center that 
processes the transactions of each of the three systems of telephone, 
chat, and e-mail, it becomes possible to average the total processing 
time taken by each operator to process the transactions of each system, 
5 thereby to make even the load of each operator. 

Moreover, it becomes possible to average the total processing 
time taken by each operator to process the transactions, in the group of 
operators each having the same skill level, thereby to make even the 
load of each operator. 

10 Furthermore, when a transaction is allocated by relaxing the skill 

level required to process the transaction, it becomes possible to 
average the total processing time taken by each operator to process the 
transactions, in the group of operators each having the same skill level, 
thereby to make even the load of each operator. 

15 Moreover, an operator whose skill level exceeds the required 

skill level by a large amount is not selected as the operator who 
processes the transaction. Therefore, it becomes possible to reduce 
the cost of the contact center. 

Furthermore, an operator whose skill level exceeds by a large 

20 amount the skill level relaxed from the required skill level is not 

selected as the operator who processes the transaction. Therefore, it 
becomes possible to reduce the cost of the contact center. 

Although the invention has been described with respect to a 
specific embodiment for a complete and clear disclosure, the appended 

25 claims are not to be thus limited but are to be construed as embodying 



all modifications and alternative constructions that may occur to one 
skilled in the art which fairly fall within the basic teaching herein set 
forth. 
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